Where Parcels Appear in the Composed Site
Two declarations decide where a group lands in the composed table of contents: the composition's own Merge Settings, and the Merge Settings each parcel carries in its deployed output. For every group it composes, the composition applies the first of these three rules that fits:
The composition places the group. A group named in the composition's Merge Settings appears exactly where the composition puts it — at the top level, or inside the containers that wrap it.
The group places itself. A group the composition does not place, but whose own Merge Settings nest it under one or more containers, appears inside those containers at the top level of the composed site.
Nothing places the group. The group is appended in discovery order — the order in which the composition finds the deployed groups at the destination (by title, then by group name). That order is the same from run to run.
The ladder is deliberately short and local. To predict where a group will appear, you read that group's own job and the composition — nothing else.
Parcel-Declared Placement
Rule 2 is what lets a federation scale across teams. Each parcel owner declares in their own job which containers their groups belong to — the shelf their content sits on — and the composition owner arranges the shelves, naming only the groups whose position they want to control. A team that publishes a new parcel does not need an edit to the composition file: the parcel arrives in the section its owner declared, as soon as it is deployed and the composition runs again.
A parcel declares its placement in Merge Settings — the same hierarchy that arranges groups in a merged help system. Nest the parcel's groups under one or more table of contents folders there, and those folders are the containers the composition places the parcel in. You can author the declaration in either of two places, and the result is the same:
In the project. Open Merge Settings for the target that produces the parcel and arrange its groups into the folder hierarchy you want. Use this when the parcel is published from a project of its own. For more information, see Merge Settings Window.
In the job. Open the AutoMap job, select the target on the Target Configuration tab, and arrange the groups on that target's Merge Settings tab. Use this when several parcels share one design and each parcel's job supplies its own arrangement, as in the job-file workflow below. For more information, see Merge Settings Tab (Target Configuration Window).
Only an arrangement you make deliberately counts as a declaration. A target that carries no merge settings of its own publishes a flat parcel that declares no placement, and rule 3 applies to it.
The declaration is recorded when the parcel builds, not when the composition runs. Each group's build writes its container chain — outermost folder first — into wwcomposition.xml, the deployed record published alongside the group, so the composition reads the arrangement out of the deployed output and never out of anyone's project. A parcel therefore carries its placement with it to whatever destination it deploys to, and changing the arrangement means rebuilding and redeploying that parcel.
Containers are matched by name. Two parcels that declare the same container name share one folder in the composed site instead of producing two, which is how independent teams land their manuals on the same shelf while coordinating nothing but the name. A shared container sits where the first parcel placed into it put it, and the parcels inside it keep discovery order. A container a parcel declares also merges with a container of the same name declared by the composition itself.
This works in the two composition modes that admit parcels the composition does not name: Automatic, which composes every group found at the destination, and a custom composition with Also include newly published parcels selected. In a strictly custom composition, only the groups you list are composed, so rule 1 covers all of them.
When rule 1 and rule 2 disagree, rule 1 wins — that is how a composition owner overrides a team's declared placement without asking the team to change its job. The composition log records the override, naming the group and the container it declared, so an unexpected position in the composed site always traces back to a line in the log. The log also lists, per container, the groups that were placed by their own declared settings.
Containers Are Not Groups
A container is a folder in the composed table of contents. A group is a set of documents with deployed output. Containers hold groups; only groups carry content. In the composition file, <TOC name="…"> declares a container and <Group name="…"/> places a group.
The distinction matters most when a container was declared by a parcel rather than by the composition. Once one team's job nests its groups under Guides, the name Guides is visible in the composed site — and it is tempting to place it in the composition's Merge Settings as though it were a group. It is not, and it has no deployed output to compose.
Note: Naming a container where a group is expected is diagnosed, not guessed. The composition omits the entry and the log identifies the name as a container, lists the deployed groups that declared it, and tells you to place those groups directly where you want them. The composed site is otherwise unaffected.
The composition also protects itself from ambiguous placement: a container declared with an empty name, and a container whose name collides with a group name at the same level, are both reported and the affected group falls back to the top level. Placement problems never fail a compose.